Application mobility with Host Identity Protocol – Extended Abstract

In this paper, we consider process migration from a communications point of view. We use the term application mobility while referring to an application being moved from a host to another during its execution. In this paper these hosts are called source and destination hosts, respectively. Moreover, we define a host to be virtual, and thus, not to equal to a physical host as such. Therefore, multiple (virtual) hosts may coexist within a physical host. The application movement should be transparent for both applications themselves and hosts they are communicating with. Neither it should compromise the security of communications. These requirements form the problem we are responding to. We enhance Host Identity Protocol (HIP)[3] to meet the requirements, because we see support for multiple Host Identities (HI) in a physical host as logical development for the HIP architecture. HIP introduces a new layer into the TCP/IP protocol stack between the transport and network layers. In essence, the HIP layer is an isolator between applications and mobility. As we include the state of the communication stack upwards from the transport layer to the migrated application state, we can migrate applications regardless of the transport and application protocols they use. The three fundamental challenges which must be addressed to provide such transparency for the transport layer, applications, and connected hosts are managing state inconsistencies, resolving state conflicts, and maintaining state syncronization[4]: Preserving connection states is difficult as the transport protocols are not designed with (application) mobility in mind, and an address change, caused by mobility, is subject to introduce state inconsistencies between the network layer and transport layer. Application mobility may create state conflicts in the transport layer. If an address is relocated together with an application to a destination host and the same address were used again in the source host, it would be possible to have connections from two hosts to a third host with identical connection invariants. Introduction of NAT (Network Address Translation) and NAPT (Network Address Port Translation) devices make state synchronization between hosts challenging as the same address:port–address:port tuple is no more usable as a connection invariant in the both communication end-points. The above challenges are the first concrete signs for us to imply that HIP might provide an elegant solution to the problem of providing transparency for the transport layer, applications and connected hosts in an application mobility architecture. To elaborate, as HIP separates the transport layer from mobility induced network address changes, HIP can offer a cure for the first two challenges. As NAT and NAPT devices do not intermix with host identities, the third challenge becomes also manageable.